@zmodem I've made some updates and now the configuration should match more closely to build_llvm_release.bat script. The main differences I know of are that the script enables openmp and this PR does not. Also, this PR is still using Wix instead of NSIS for the installer generator.

I'm having a lot of trouble getting the build_llvm_release.bat script to run inside the github actions environment. Has anyone tried running it lately from the main branch where it builds the code from main and not code from a release?

Has anyone tried running it lately from the main branch where it builds the code from main and not code from a release?

I just tried it, and yes there are a number of issues after @omjavaid's #131687 I suppose I should have tested it, not just reviewed it :-p

(I build with build_llvm_release.bat --x86 --x64 --force-msvc --version=21.1.4)

Firstly check-sanitizers doesn't exist in the runtimes build. Switching to check-runtimes hits a bunch of ASan errors on 32-bit. The 32-bit ASan runtime isn't really supported, so I think we should pass -DCOMPILER_RT_BUILD_SANITIZERS=OFF in 32-bit builds.

For 64-bit, check-runtimes also hits some issues. First, this target runs more tests than the old one, including the orcjit tests which don't pass. I think that's is a known issue, and we should pass -DCOMPILER_RT_BUILD_ORC=OFF (https://lab.llvm.org/buildbot/#/builders/107 does that). Some libfuzzer tests hang for me. I don't know if those used to run before under the old build target. And some ASan tests fail too. They're very sensitive.

I'm still fiddling with this.

It seems the arm64 packages solves this by not building the sanitizers and also not running the runtimes tests :)

bcb3d2f lets me get through packaging of 21.1.4. Does that address the issues you were seeing?

@tstellar could you also include windows-11-arm builds as well. Currently we are using release script from #131687 to do LLVM Windows on Arm builds.
@omjavaid Sorry I missed this. We don't have the resources yet to do a full build on AArch64. The best we could probably do is a build with PGO disabled and we might need to disable some projects too.

bcb3d2f lets me get through packaging of 21.1.4. Does that address the issues you were seeing?

Thank you. I will test this and get back to you.

@zmodem I'm seeing some errors building openmp, but I'm also building main using the --skip-checkout option and not the 21.1.4 release.

Logs here:
https://github.com/llvm/llvm-project/actions/runs/19373045853/job/55433478607?pr=150793

Logs here:
https://github.com/llvm/llvm-project/actions/runs/19373045853/job/55433478607?pr=150793

The first error is:

2025-11-14T18:08:50.4596533Z FAILED: [code=1] openmp/runtime/src/CMakeFiles/omp.dir/kmp_csupport.cpp.obj 
2025-11-14T18:08:50.4601282Z S:\llvm\utils\release\llvm_package_21.1.4\build_amd64_stage0\bin\clang-cl.exe --target=x86_64-pc-windows-msvc  /nologo -TP -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_GLIBCXX_NO_ASSERTIONS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Domp_EXPORTS -IS:\llvm\utils\release\llvm_package_21.1.4\build_amd64_stage0\runtimes\runtimes-bins\openmp\runtime\src -IS:\openmp\runtime\src -IS:\openmp\runtime\src\i18n -IS:\openmp\runtime\src\include -IS:\openmp\runtime\src\thirdparty\ittnotify /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive- -Werror=unguarded-availability-new /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd5105 -wd4324 -wd4251 -wd4275 -w14062 -we4238 /Gw -fcolor-diagnostics -Wcast-qual -Wformat-pedantic -Wimplicit-fallthrough -Wsign-compare -Wno-extra -Wno-pedantic -wd4201 -wd4190 /O2 /Ob2 /DNDEBUG -std:c++17 -MT   -D _CRT_SECURE_NO_WARNINGS -D _CRT_SECURE_NO_DEPRECATE -D _WINDOWS -D _WINNT -D _WIN32_WINNT=0x0501 -D _USRDLL -Wno-covered-switch-default -Wno-frame-address -Wno-strict-aliasing -Wno-switch -Wno-uninitialized -Wno-return-type-c-linkage -Wno-cast-qual -Wno-int-to-void-pointer-cast /GS /EHsc -mrtm /showIncludes /Foopenmp\runtime\src\CMakeFiles\omp.dir\kmp_csupport.cpp.obj /Fdopenmp\runtime\src\CMakeFiles\omp.dir\ -c -- S:\openmp\runtime\src\kmp_csupport.cpp
2025-11-14T18:08:50.4612059Z S:\openmp\runtime\src\kmp_csupport.cpp(1349,52): error: use of undeclared identifier 'omp_lock_hint_none'
2025-11-14T18:08:50.4612712Z  1349 |   __kmpc_critical_with_hint(loc, global_tid, crit, omp_lock_hint_none);
2025-11-14T18:08:50.4614233Z       |

I think omp_lock_hint_none is defined in openmp/runtime/src/include/omp.h.var which should get processed by cmake (openmp/runtime/src/CMakeLists.txt) into omp.h in clang's resource dir:

# The generated headers will be placed in clang's resource if using it to
# compile openmp in a runtimes-bootstrapping build.
if(LLVM_TREE_AVAILABLE AND LLVM_RUNTIMES_BUILD)
  set(LIBOMP_HEADERS_INTDIR ${LLVM_BINARY_DIR}/${LIBOMP_HEADERS_INSTALL_PATH})
else()
  set(LIBOMP_HEADERS_INTDIR ${CMAKE_CURRENT_BINARY_DIR})
endif()

I guess it somehow failed to generate the header, or at least didn't put it in the right place?

Is it possible to run with higher cmake verbosity to see if/where it writes that file?

Being paranoid: could there be some weird interaction between passing --version 21.1.4 but building trunk which is 22.0.0? (imaybe openmp gets the version number in clang's resource dir wrong due to this somehow)

fwiw llvm\utils\release\build_llvm_release.bat --version 22.0.0-rc0 --skip-checkout --x64 --force-msvc seems to work for me on trunk (af45b02)

Being paranoid: could there be some weird interaction between passing --version 21.1.4 but building trunk which is 22.0.0? (imaybe openmp gets the version number in clang's resource dir wrong due to this somehow)

I think this fixed the OpenMP error. However, I'm starting to have problems with the python detection, but this seems like a change it's caused by a change in the GitHub environment recently and not with the script.